1. Field of the Invention
The present invention relates to software which can run on a plurality of environments having different specifications and, more particularly, to a runtime environment dependency hiding apparatus and method which can achieve easy maintenance and high re-usability of software by hiding a part that depends on the runtime environment in software to make it invisible, and a computer readable recording medium that records a runtime environment dependency hiding program.
2. Related Background Art
Since source code of software is normally converted by a compiler into that in a runtime format premised on an operating system, peripheral devices, command sets unique to a CPU, and the like, the runtime format generated from source code depends on the platform such as an operating system and the like.
Since such platform dependence of software is a serious bottleneck upon development and distribution of versatile software, system development using Java (tradename) language has prevailed recently. Source code of a Java program developed using the Java language is converted by a compiler into intermediate code format called bytecode, and the bytecode is executed by a Java interpreter which runs on a VM (Virtual Machine). For this reason, when VMs are prepared in units of platforms, the runtime format (bytecode) is independent from any single platform.
However, since there are a plurality of specifications of VMs that execute Java programs and a plurality of specifications of WWW (World Wide Web) browsers that execute Java applets as a kind of Java program, the actual Java program depends on the runtime environment of, e.g., a VM.
Platform dependence of a Java program will be explained taking as an example a Java program executed by a VM that runs on an operating system. There are two major VMs that execute Java programs:
(1) a VM (JDK VM) complying with the JDK (Java Development Kit) available from Sun Microsystems Inc.; and
(2) a VM (MS VM) available from Microsoft Corp. (which is not fully compatible with the JDK).
These VMs use different specifications of native method interfaces which define rules that establish correspondence between a program described in the Java language and a program described in other languages such as C, C++, and the like.
FIG. 15 shows an example of coding of a Java program that uses the native method interface, and FIG. 16 is an explanatory view of the native method interface. Referring to FIG. 15, source code (Java code) of a Java program that uses a program (native code) described in another language contains: a description (system.loadLibrary(“lib_for_native”);) that loads a shared library (embedded in other languages such as C, C++, and the like) that stores native code fragments corresponding to native methods; and a description (public native void show( );) that declares a given method as a native method. Note that as shown in FIG. 16, the method declared as the native method calls corresponding native code from the shared library loaded into the Java program via the native method interface upon execution.
In the native method interface, rules that pertain to the way of describing native code are defined in detail so as to allow native code to exchange information with Java code. Such rules include:
(1) a naming rule between the native method and the functions of the native code; and
(2) functions used for accessing Java objects from native code; and so on.
The native method interface is provided by a VM, but its kind varies depending on the kinds of VMs. However, when both the aforementioned JDK VM and MS VM use the native method interface, JNI (Java Native Interface) is used in case of the JDK VM; RNI (Raw Native Interface) is used in case of the MS VM, thus commonizing Java code, as shown in FIG. 15.
However, in either native method interface of the JNI and RNI, a shared library that stores a native code fragment must be loaded into a Java program before native code is used. Since the description style of native code varies depending on the kinds of native method interfaces, different shared libraries must be prepared in correspondence with different kinds of native method interfaces (JNI and RNI), and the shared library name to be loaded must be switched in correspondence with the kind of the runtime VM, as shown in FIG. 17.
FIG. 18 shows an example of coding of a Java program upon switching the shared library name to be loaded in correspondence with the kind of VM. In a Java program shown in FIG. 18, after the value of a “java.vendor” property as one of system properties is acquired (see field (A) in FIG. 18), the kind of VM is checked based on the acquired value using an “if” statement, and the shared library name to be loaded is switched on the basis of the checking result (see field (B) in FIG. 18). Note that the system properties correspond to environment variables used in an operating system or the like, and include standard system properties (standard properties) given upon execution, and non-standard system properties (non-standard properties) that can be set as needed. The standard properties include a “java.vendor” property, “os.name” property, and the like corresponding to the vendor name of the runtime VM, the operating system name, and the like, and the values of these standard properties are acquired by a “getProperty” method of a “java.lang.System” class contained in a standard class library of the Java language. On the other hand, a shared library specified based on the value of the standard property is loaded into the Java program by a “loadlibrary” method of the “java.lang.System” class contained in the standard class library of the Java language.
As described above, in a Java program that uses the native method interface, a part for switching the shared library name to be loaded in correspondence with the kind of VM is implemented by a conditional description (“if” statement) in Java code.
However, in such a Java program, since information (“Microsoft”, “SUN Microsystems”) as a basis for switching decision, the shared library name (“MS”, “SUN”) to be loaded, and the like are directly written in Java code (see the italics in FIG. 18), re-compiling is required every time information as a basis for switching decision, the shared library name, and the like are added/changed, resulting in poor maintenance and re-usability.
For example:
(1) When another company (A company) other than Sun Microsystems, Inc. and Microsoft Corp. provides a new VM, a new conditional description that determines the kind of VM provided by A company and switches the shared library name to be loaded must be added.
(2) When Microsoft Corp. changes its policy so as to support the JNI as a native method interface in place of the RNI, the shared library name as a result of checking the kind of VM provided by Microsoft Corp. needs to be changed.
In order to reflect the addition/change in the above-mentioned cases (1) and (2) in a Java program, Java code must be modified and re-compiled into a runtime format (bytecode).